集約されたクライアントパケットのトランスポート

专利摘要:
本発明は、パケットトランスポートネットワークを介して１つまたは複数のクライアント信号を伝送するための方法に関する。この方法によれば、この１つまたは複数のクライアント信号のパケットが、ネットワークの入口ノードにおいて受信される。これらの受信されたパケットのタイミングを特徴付けるタイミング情報が、決定され、これらの受信されたパケットが、コンテナの中にマッピングされる。このコンテナ、およびこのタイミング情報は、ネットワークを介して伝送される。ネットワークの出口ノードにおいて、これらのパケットが、このコンテナから抽出され、パケットは、伝送されたタイミング情報に基づいて、さらなる伝送のためにタイミング制御される。
公开号:JP2011507430A
申请号:JP2010538597
申请日:2008-12-11
公开日:2011-03-03
发明作者:ラオテンシユラガー，ボルフラム
申请人:アルカテル−ルーセント；
IPC主号:H04L29-08

专利说明:

[0001] 本発明は、光通信に関し、詳細には、パケットトランスポートネットワークを介して１つまたは複数のクライアント信号の集約されたパケットを伝送する方法に関する。さらに、本発明は、そのようなパケットトランスポートネットワークのためのネットワーク要素、およびパケットトランスポートネットワーク自体に関する。]
背景技術

[0002] パケットネットワークにおいて、パケットサイズ、データ転送速度、および転送遅延の３つの要素が、本質的に互いに結び付いている。パケット、例えば、イーサネット（登録商標）パケットは、エンドユーザアプリケーションのニーズに対して、特に、アプリケーションに関して許容可能な転送遅延をもたらすことに対して、通常、サイズがよく適合している。エンドユーザの通常のデータ転送速度において、パケットサイズは、人間の時間的知覚限界を下回る転送遅延をもたらすように大きさが決められている。例えば、１０００バイトのサイズを有するイーサネット（登録商標）パケットは、毎秒６４キロビットのデータ転送速度を有する音声呼データによって埋められるのに１２５ミリ秒かかり、その結果、１２５ミリ秒の範囲内の転送遅延をもたらす。このため、小さいエンドユーザデータ転送速度で実行されるアプリケーションは、小さいパケットサイズを好み、これにより、人間の時間的知覚限界を下回るように転送遅延を低減する。]
[0003] コアネットワークにおいて、パケットのさらなるパケットサイズ依存の転送遅延は、アプリケーションデータ転送速度からコアデータ転送速度に速度が上げられることにより、より小さい。しかし、アプリケーション（特に、例えば、毎秒１０メガビットのデータ転送速度を有するビデオストリーミングアプリケーションなどの高いデータ転送速度を有するアプリケーション）は、他の遅延寄与のため、この小さい転送遅延の利益を受けることができない。例えば、コアネットワークにおける１０００キロメートルの距離のファイバ伝搬遅延は、５ミリ秒の範囲内にある（パケットサイズとは無関係に）のに対して、そのようなコアネットワークのノードにおいて、１０００バイトのサイズを有するパケットのパケットサイズ依存の転送遅延は、他のすべての遅延寄与よりはるかに小さい１マイクロ秒という小ささである。このため、コアネットワークにおける全体的な追加の転送遅延は、コアネットワークにおける小さいパケットサイズ依存の転送遅延によって支配されるのではなく、大部分、他の遅延寄与によって決まる。また、コアネットワークにおけるパケットサイズ依存の転送遅延が小さいことは、より大きいパケットサイズを許しもする。しかし、前述したとおり、通常、パケットサイズは、ユーザアプリケーションのニーズによって決定される。]
[0004] プロトコルパケットは、さらに小さいパケットサイズを有することが可能である。最小のパケットの中には、６４バイトのサイズを有する、広く使用されるＴＣＰ（伝送制御プロトコル）ＡＣＫパケットがある。このパケットは、ＴＣＰにおいてパケットの受信を確認するために使用され、既存のインターネット慣行において避けることができない。]
[0005] 高速コアネットワークにおいて、クライアントトラフィックは、容量で集約され、それでも、それぞれの個別のクライアントパケットが、コアにおいて個々に転送される。このため、パケット粒度は、エンドユーザアプリケーションからコアネットワークで変化しない。コアネットワークの入口ノードにおいて、各クライアントパケットは、Ｔ−ＭＰＬＳ（トランスポートマルチプロトコルラベルスイッチング）、ＰＢＢ（プロバイダバックボーンブリッジ）、またはＭＡＣ−ｉｎ−ＭＡＣのような１：１カプセル化技術の使用によって、コアネットワークを介する伝送のために別々にカプセル化されることが可能であり、すなわち、１つのイーサネット（登録商標）パケットが、別のイーサネット（登録商標）パケットの中にカプセル化されることが可能である。カプセル化されたパケットは、不透明であり、すなわち、コアネットワークには不可視である。]
[0006] コアネットワークにおける高いデータ転送速度において、ユーザアプリケーションによって決定された不変のパケットサイズは、各パケットのヘッダがコアネットワークにおいて処理されるので、コアネットワークにおける同一のパケット（または別のパケットの中に１：１カプセル化された）の効率的なトランスポートのためには余りにも小さ過ぎる。コアネットワークのライン速度が高いほど、ヘッダ処理のための労力も大きい。さらに、コアネットワーク要素のパケット処理能力は、最大負荷および最小パケットサイズという最悪ケースにおいてさえ、十分であるように設計されなければならない。そのようなシナリオは、生じる可能性が低いが、安全には排除され得ない。このため、毎秒１０ギガビットのため、毎秒１００ギガビット以上のため、例えば、毎秒１００ギガビットのイーサネット（登録商標）のためのコアネットワークラインカードにおいて、パケットのヘッダ処理は、電力およびシリコン面積を最も多く消費するタスクである。]
[0007] ヘッダ処理の労力を減らすためのよく知られたアプローチは、より小さいサイズのパケットを、より大きいサイズのコンテナの中に集約することであり、例えば、ＯＢＳ（光バーストスイッチング）において、パケットを、より大きいコンテナ（バーストまたはフレームとも呼ばれる）の中に入れてバースト化することが、使用される。ネットワーク入口ノードにおいて、同一の宛先を有するパケットが、蓄積されて、コンテナの中に集約され、このコンテナが、次に、不透明なエンティティとしてコアネットワークを通って移動させられる。それぞれのネットワーク出口ノードにおいてだけ、このコンテナは、アンロードされ、包含されるパケットが、クライアントネットワークに解放される。ＯＢＳにおいて、パケットをコンテナの中に集約することは、光学デバイスのスイッチング速度が低いために、必要である。集約なしには、光学デバイスは、パケットに関して切り換えられなければならず、このことは、可能ではない。電子スイッチングまたは光電子スイッチングの場合、パケットを蓄積し、これらの蓄積されたパケットをコンテナの中に集約するという概念は、コアスイッチにおける毎秒のパケットカウントを減らすために再使用されることも可能である。]
[0008] コンテナの中に集約し、そのようなコンテナを集約解除するプロセスは、少なくとも２つの欠点をもたらす。
１．低い負荷の場合、最初（すなわち、集約前に）、よく分離されていたまばらなパケットが、コンテナの中でパケットのタイミングが失われるので、コアネットワークを介する伝送の後、パケットのバーストの中でひとかたまりになっている可能性がある。このことは、コアネットワークの出口ノードの下流にある、より下位のネットワークに問題をもたらす。
２．そのようなコアネットワークの入口ノードにおける可変のトラフィック負荷は、コンテナのためにパケットを蓄積することに関して、可変の蓄積時間をさらにもたらす。蓄積時間の、この不確実性は、コンテナの間で遅延の時間的ばらつきをもたらし、このため、集約解除の後のパケット着信の大きいジッタをもたらす。そのようなジッタは、例えば、一定のパケット時間距離を必要とするストリーミングアプリケーションには問題である。]
[0009] 以下に、集約解除後のパケットフローの高いバースト性の問題を詳細に説明する。]
[0010] 境界に、より低速のアクセスネットワークを有し、中間に高速のコアネットワークを有する階層ネットワークにおいて、パケットフローのタイミングは、極めて重要なパラメータである。通常、パケットフローは、送信元ネットワークによって自然にシェーピングされる。パケット間の時間的距離は、伝送が、送信元ネットワークにも、受信側ネットワークにも過負荷をかけないことを確実にする。コアネットワークは、他のトラフィックによる負荷とは無関係に、さらに個々のフローの明示的な知識なしに、パケットフローのタイミングを保たなければならない。このことは、ＷＦＱ（Ｗｅｉｇｈｔｅｄ Ｆａｉｒ Ｑｕｅｕｉｎｇ）またはＷＲＲ（Ｗｅｉｇｈｔｅｄ Ｒｏｕｎｄ Ｒｏｂｉｎ）のようなキューイングスキームおよびスケジューリングスキームを使用することによって、確実にされる。]
[0011] 高速コアネットワークを介してクライアントパケットを伝送することに関して、クライアント信号の細粒度のパケットは、例えば、ＳＤＨ（ＩＴＵ−Ｔ Ｇ．７０１において規定される同期デジタル階層）、ＳＯＮＥＴ（Ｔｅｌｃｏｒｄｉａ社からのＧＲ−２５３−ＣＯＲＥにおいて規定される同期光ネットワーキング）、またはＯＴＮ（ＩＴＵ−Ｔ Ｇ．７０９において規定される光トランスポートネットワーク）の場合に、より大きいトランスポートコンテナの中に入れられて、通常、カプセル化される。これらすべてのトランスポートプロトコルは、コンテナが、連続して移動するＴＤＭ（時分割多重化）エンティティ（同期トラフィック）であり、つまり、コンテナが、コンテナのロードにかかわらず、トランスポートプロトコルのデータ転送速度に従って、連続して生成されて、伝送されるという共通点を有する。クライアントパケットは、オンザフライでコンテナの中にマッピングして入れられる。散発的なパケットストリームの場合、コンテナは、必要に応じて、アイドルパターンによって埋められる。このため、互いに対するパケットの相対的タイミングは、そのような高速ネットワークの入口ノードから、そのようなネットワークの出口ノードまで変化しない。]
[0012] このことは、パケットを蓄積すること、および蓄積されたパケットをコンテナの中に集約することを伴うパケットトランスポートネットワークにおいて、例えば、バースト交換ネットワークまたはフレーム交換ネットワークにおいて通常は当てはまらない。そのようなネットワークは、依然として、研究されており、まだ完全に標準化されていない。そのようなネットワークにおいて、複数の小さいクライアントパケットが、ネットワークコアにおけるスイッチングオーバーヘッドを節約するように、より大きいコンテナの中に集約される。]
[0013] バースト交換ネットワークは、ＯＢＳの概念に基づく。バースト交換ネットワークにおいて、１つまたは複数のクライアント信号のより小さいパケットが、或る特定の出口ノードに伝送されるべき、より大きいバーストの中に集約される。ネットワークを介してバーストを伝送する際、ネットワークの光バーストスイッチが、ネットワークの入口ノードから、それぞれの出口ノードまで個別のバーストを転送するように切り換えられる。]
[0014] また、フレーム交換ネットワークにおいて、１つまたは複数のクライアント信号の複数のより小さいパケットが、より大きいフレームの中に集約される。フレーム（負荷に依存する）を埋めた後、フレームは、個別のエンティティとして同期高速トランスポートストリームに入るように切り換えられる。Ｇ．Ｅｉｌｅｎｂｅｒｇｅｒの論文、「Ｌｏｎｇ ｔｅｒｍ ｎｅｔｗｏｒｋ ａｒｃｈｉｔｅｃｔｕｒｅｓ ａｎｄ ｓｃｅｎａｒｉｏｓ ｂａｓｅｄ ｏｎ ｏｐｔｉｃａｌ ｂｕｒｓｔ／ｐａｃｋｅｔ ｓｗｉｔｃｈｉｎｇ」、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＳＰＩＥ、ＡｓｉａＰａｃｉｆｉｃ Ｏｐｔｉｃａｌ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ２００６、２００６年９月、韓国光州市、Ｖｏｌ．６３５４が、セクション３．１において、Ｇ．７０９標準の変形に基づくフレーム交換ネットワークの例を開示している。この開示は、参照により本明細書に組み込まれている。フレームが、ネットワークのノード内部で個々のエンティティとして切り換えられる一方で、ノード間の伝送リンクは、Ｇ．７０９に準拠する連続的な同期伝送を維持する。追加／ドロップマルチプレクサにおいて、クライアントインタフェース信号が、フレーム集約ユニットによって、適応されたＧ．７０９フレームフォーマットに入るように集約される。フレームを埋めた後、フレームは、同期トランスポートストリームに入るように個々に切り換えられ、すなわち、フレームは、固定の周期で高速トランスポートストリームに入るように周期的に切り換えられることはない。]
[0015] バースト交換ネットワークおよびフレーム交換ネットワークにおいて、通常、完成を待ってから伝送される、複数のクライアントパケットを含む、より大きいサイズのコンテナ（すなわちバースト交換ネットワークの場合、バースト、フレーム交換ネットワークの場合、フレーム）が、使用される。そしてコンテナの完成は、実際のトラフィック負荷に依存する。パケット間のアイドルパターンは、例えば低いトラフィック負荷の場合、一般には使用されない。クライアントパケットは、入口ノードにおける相対的タイミングにかかわらず、次々にコンテナの中にカプセル化される。充填パターンは、コンテナの終わりになって初めて出現することが可能である。出口ノードにおいて、コンテナの中のカプセル化されたパケットは、アンロードされて、アクセスネットワーク（またはメトロネットワーク）に解放される。しかし、この時点で、パケット間の元のタイミングは、もはや利用可能ではない。トラフィック負荷に依存して、クライアントパケットは、バーストの中で一緒にひとかたまりにされる可能性がある。このことは、下流のネットワークバッファにかかる高い負担をもたらす。特に、低いトラフィック負荷の場合、出口ノードにおけるパケットフローの高いバースト性が、容易に生じる可能性がある。そのような高いバースト性は、パケットが入口ノードに入った際、存在していなかった。]
[0016] この問題は、図１から図３を参照して、より詳細に説明される。] 図１ 図３
[0017] 図１は、従来の同期高速コアネットワーク（例えば、ＳＤＨネットワーク）と、境界における１つまたは複数の、より低速のアクセスネットワークまたはメトロネットワークとを有する従来の階層ネットワークにおけるクライアントパケットフローを示す。通常、より低い速度のアクセスネットワークは、さらに下位の配信ネットワークに接続される。例えば、企業ネットワーク内に位置する送信側ノード（近端）１から、より低いデータ転送速度のクライアント信号２が、アクセスネットワークを介して、高速コアネットワークの入口ノード３に伝送される。このより低いデータ転送速度のため、信号２のパケットは、図１に示される相対的に長い持続時間を有する。入口ノード３は、（データ転送速度を増加させることによって）パケット持続時間を短縮するための手段４と、これらのパケットを他のクライアント信号と一緒に多重化して、連続的な高速トランスポート信号６、例えば、毎秒１０ギガビットのＳＤＨ信号の中に入れるための多重化手段５とを提供する。別々のユニットとして示されるものの、通常、手段４と手段５はともに、単一のユニット内で実現される。コアネットワークを介して出口ノード７に伝送した後、プロセスは、逆転される、すなわち、受信された高速トランスポート信号６が、逆多重化手段８によって様々なクライアント信号に逆多重化されて、この逆多重化された信号のパケット持続時間が、適切な手段９によって増加させられる。出口ノード７から、クライアント信号１０は、より低速のアクセスネットワーク、および他の、より下位の配信ネットワークを介して宛先に転送される。図１に示される遠端１１は、パケットフローがバースト性である場合に問題が生じる可能性がある、宛先より前の最後の中間ノード（例えば、フロア配線盤またはＤＳＬアクセスマルチプレクサ）の１つを表し、すなわち、遠端１１は、出口ノード７の背後のボトルネックを表す。しかし、図１に示されるとおり、入口ノード３における信号２の受信されたパケットのフローは、出口ノード７における信号１０の転送されたパケットのフローに対応し、すなわち、フロー形状は保たれており、全く問題は生じない。] 図１
[0018] 図２は、重い負荷の場合に負荷依存のコンテナ生成を伴うバースト交換コアネットワークまたはフレーム交換コアネットワークを有する階層ネットワークにおけるクライアントパケットフローを示す。同一の符号によって表される図１と図２における図示される要素は、基本的に同一である。図２において、多重化手段５’が、様々なクライアント信号のパケットをコンテナ２０ａ−ｃの中に集約するためにさらに構成され、さらに逆多重化手段８’がやはり、コンテナ２０ａ−ｃからパケットを抽出するために構成される。クライアントパケットは、入口ノードにおける相対的タイミングにかかわらず、コンテナの中に次々に入れられる。重い負荷の場合、１つのクライアント信号の限られた数のパケット（この場合、１つのコンテナ当たり１つのパケット）が、１つのコンテナの中に集約される。出口ノード７においてクライアント信号２のパケットを抽出し、手段９においてパケット持続時間を適応させた後、これらのパケットは、宛先に転送される。図２に示されるとおり、入口ノード３’における信号２の受信されたパケットのフローは、出口ノード７における信号１０の転送されたパケットのフローに基本的に対応する。このため、コンテナの中に集約することは、フロー形状を全く乱さない、または無視できるほどわずかしか乱さない。] 図１ 図２
[0019] 図３は、図２のネットワークの負荷が低い場合におけるクライアントパケットフローを示す。同一の符号によって表される図２と図３における図示される要素は、基本的に同一である。図３における低い負荷のため、クライアント信号の、より多くのパケットが、１つのコンテナの中に集約されることが可能であり、例えば、クライアント信号２の２つのパケットが、第１のコンテナ２０ｄの中に集約されることが可能である。出口ノード７’においてクライアント信号２のパケットを抽出し、手段９においてパケット持続時間を適応させた後、これらのパケットは、一緒にひとかたまりにされ、遠端１１における低速リンクに重点を置いている。出口ノード７におけるフローのそのような高いバースト性は、このバースト性が、遠端において一時的に過負荷を生じさせるので、下流のネットワークバッファに負担をかける。このことは、コンテナ交換トランスポートネットワークから遠く離れ、このネットワークを認識していない宛先ホストの近くのアクセススイッチ、または顧客によって所有されるスイッチにさえ、最小のバッファが、通常、設置されるので、さらに悪い。その結果、そのようなネットワークのコンテナの中にパケットを集約することは、トラフィック形状の変形を生じさせるだけでなく、現実の根本的原因から遠く離れて、接続の遠端で、適切な軽減の可能性が低い問題を生じさせる。] 図２ 図３
先行技術

[0020] ＩＴＵ−Ｔ Ｇ．７０１
ＧＲ−２５３−ＣＯＲＥ
ＩＴＵ−Ｔ Ｇ．７０９
Ｇ．Ｅｉｌｅｎｂｅｒｇｅｒ、「Ｌｏｎｇ ｔｅｒｍ ｎｅｔｗｏｒｋ ａｒｃｈｉｔｅｃｔｕｒｅｓ ａｎｄ ｓｃｅｎａｒｉｏｓ ｂａｓｅｄ ｏｎ ｏｐｔｉｃａｌ ｂｕｒｓｔ／ｐａｃｋｅｔ ｓｗｉｔｃｈｉｎｇ」、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＳＰＩＥ、ＡｓｉａＰａｃｉｆｉｃ Ｏｐｔｉｃａｌ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ２００６、２００６年９月、韓国光州市、Ｖｏｌ．６３５４
ＩＴＵ−Ｔ Ｇ．７０４１
ＩＥＥＥ８０２．３]
発明が解決しようとする課題

[0021] このため、本発明の目的は、パケットトランスポートネットワークを介してクライアントパケットを伝送するための方法を提供することであり、この方法は、低減されたヘッダ処理能力を許す。この方法は、前述したとおり、出口ノードにおけるフローの高いバースト性の問題を克服しなければならない。本発明のさらなる目的は、そのようなパケットトランスポートネットワークの入口ノードおよび出口ノードのための対応するネットワーク要素を提供し、さらにそのようなネットワーク自体を提供することである。]
課題を解決するための手段

[0022] これらの目的は、独立請求項による方法、ネットワーク要素、およびトランスポートネットワークによって達せられる。]
[0023] 本発明の第１の態様は、パケットトランスポートネットワークを介して１つまたは複数のクライアント信号（例えば、イーサネット（登録商標）信号、またはＩＰ／ＰＰＰ、すなわち、インターネットプロトコル／ポイントツーポイントプロトコル信号）を伝送するための方法に関する。]
[0024] この方法は、パケットトランスポートネットワークの入口ノードにおいて、複数のパケットを、より大きいコンテナ（例えば、イーサネット（登録商標）ジャンボフレーム）の中に集約すること、特に、負荷に依存して集約することを、出口ノードにおいてクライアントフロータイミングを再現するための手段と組み合わせて提案する。]
[0025] 中間のノードにおいて、コンテナヘッダだけが処理され、パケットヘッダは処理されないことが可能である。このため、コンテナのヘッダだけが、コアネットワークに可視であり、カプセル化されたパケットのヘッダは、コアネットワークに可視ではない。そのような集約は、少なくとも１／１００に最悪ケースのパケットヘッダ処理（例えば、毎秒１０ギガビットまたは毎秒１００ギガビットのイーサネット（登録商標）リンク）を減らすことができる。]
[0026] 本発明は、特に、実際のトラフィック負荷、およびこの負荷のばらつきとは無関係に、出口ノードにおいてクライアントフロータイミングを再現するための手段を提供することによって、集約に起因する問題（例えば、トラフィック形状問題、ジッタが生じる問題、および一般的なタイミング問題）に対処する。このため、学問的な研究で検討されるコンテナ集約の概念が、アクセス層およびアプリケーション層に悪影響を与えることなしに、生産的なネットワークにおいて使用されることが可能である。]
[0027] 入口ノードにおいて受信されたパケットのタイミング情報を決定し、さらにパケットトランスポートネットワークを介して、このタイミング情報を伝送することによって、コンテナの中のパケットの元の相対的パケットタイミングが、コアネットワークにおいて再構築されることが可能である。]
[0028] ヘッダカウントは、基本的に一定（すなわち、実際のトラフィックとは無関係の）低いレベルに制限されることが可能である。低い負荷の場合、例えば、１つまたは２つのパケットだけがコンテナの中に含まれるのに対して、高い負荷の場合、多くのパケットが、コンテナの中にカプセル化される。両方の場合に、コアネットワークは、コンテナロードにかかわらず、コンテナのヘッダを処理するだけでよい。このことは、トランスポートネットワークにおいて、特に、トランスポートネットワークのスイッチにおいて、ヘッダ処理労力を低減する。このため、トランスポートネットワークにおけるネットワーク要素のヘッダ処理能力が、低減されることが可能であり、あるいは同一の処理能力で、全体のスループットが増加されることが可能である。]
[0029] 本発明の方法によれば、１つまたは複数のクライアント信号のパケットが、ネットワークの入口ノードで受信され、蓄積される。受信されたパケットのタイミングを特徴付けるタイミング情報が、決定され、これらの受信されたパケットが、コンテナの中にマッピングされる。例えば、パケット着信の相対的距離が、これらのパケットと一緒に格納される。このコンテナ、およびこのタイミング情報が、ネットワークを介して伝送される。好ましくは、このタイミング情報は、コンテナの一部として伝送される。ネットワークの出口ノードにおいて、これらのパケットが、コンテナから抽出され、これらのパケットは、伝送されたタイミング情報に基づいて、さらなる伝送のためにタイミング制御される。このタイミング制御は、パケットがコンテナから抽出される前に実行されても、抽出された後に実行されても、抽出されるのと同時に実行されてもよい。]
[0030] 提案される方法は、パケットをコンテナの中に集約する場合に、受信されたパケットのタイミングが失われないという利点をもたらす。代わりに、入口ノードにおける受信されたパケットのタイミングを特徴付けるタイミング情報が、決定され、出口ノードに伝送される。このため、伝送されたタイミング情報に基づいて、出口ノードにおける抽出されたパケットのタイミングが、入口ノードにおける受信されたパケットのタイミングに基本的に対応するように、出口ノードにおいてタイミングが、復元されることが可能である。このため、出口ノードにおける転送されたパケットフローの高いバースト性が、回避され、その結果、遠端における一時的過負荷の問題が回避される。つまり、アンロード段階において、パケット着信プロセスが、パケットと一緒に格納された、正しい出発距離を再確立することによって、模倣されることが可能である。]
[0031] 提案されるソリューションは、この問題をトランスペアレントに解決し、すなわち、このソリューションは、コンテナ集約およびコンテナ集約解除のプロセスにローカルであり、このソリューションは、コアにおけるアプリケーションフローの明確な認識を要求せず、さらにこのソリューションは、影響を受ける遠端のアクセスリンクには不可視である。このため、アプリケーションフロー形状は、個々のフローに特別な注意を払うことなしに、再現される。]
[0032] 本発明の方法を実施するために、コア出口ノードにおける集約解除のためのさらなる遅延、すなわち、さらなるバッファ空間が、要求される可能性がある。]
[0033] 本発明の方法は、クライアントパケットカプセル化を使用し、このため、Ｔ−ＭＰＬＳ（トランスポートマルチプロトコルラベルスイッチング）、ＰＢＢ（プロバイダバックボーンブリッジ）、またはＭＡＣ−ｉｎ−ＭＡＣのような従来のクライアントパケットカプセル化スキームに適用可能であり得る。そのような従来の１：１（すなわち、１つのコンテナ当たり１つのパケット）のクライアントパケットカプセル化スキームは、１つのコンテナ当たり複数のパケットをサポートするように本発明の方法によって拡張されることが可能である。]
[0034] 集約されたトランスポートストリームは、標準のパケット技術、例えば、イーサネット（登録商標）に準拠することが可能である。]
[0035] 好ましくは、パケットのタイミング情報を決定するステップ、およびパケットをマッピングするステップは、変形されたＧＦＰ（汎用フレーミングプロシージャ）によって実行される。]
[0036] ＩＴＵ−Ｔ Ｇ．７０４１において規定される従来のＧＦＰにおいて、異なるタイプ（例えば、イーサネット（登録商標）ＭＡＣ、ＩＰ／ＰＰＰ）のクライアントパケットが、汎用フレームフォーマットに入るように、すなわち、ＧＦＰコアヘッダと、ＧＦＰペイロード領域とを有するＧＦＰクライアントデータフレームの中に入るように符号化される。詳細には、クライアントパケットは、ＧＦＰペイロード領域の中にマッピングされる。このＧＦＰクライアントデータフレームが、次に、トランスポートプロトコルのフレーム、例えば、ＳＤＨフレーム、ＳＯＮＥＴフレーム、またはＯＴＮフレームの中にマッピングされる。伝送のために利用可能なＧＦＰフレームが全く存在しない場合、ＧＦＰアイドルフレームが、受信されたクライアントパケットの間に挿入される。ＧＦＰアイドルフレームは、充填フレームとして使用されて、任意の所与のトランスポート媒体にＧＦＰストリームを適用させることを円滑にし、このトランスポート媒体は、クライアント信号によって要求されるより高いデータ容量を有する。このことは、フレームの連続的なストリームをもたらす。２００５年８月のＩＴＵ−Ｔ Ｇ．７０４１文書、特にＧＦＰアイドルフレームと関係するコメントが、参照により本明細書に組み込まれている。]
[0037] 後続のＧＦＰクライアントデータフレームの間の、したがって、後続のクライアントパケットの間のＧＦＰアイドルフレームの数は、受信されるフレームのタイミングに依存し、さらには、入口ノードで受信されるクライアントパケットのタイミングに関する尺度である。]
[0038] 本発明の好ましい実施形態によれば、変形されたＧＦＰによって、受信されたパケットを符号化する際、クライアントパケットの間のＧＦＰアイドルフレームは、脱落させられ、２つのパケットの間の脱落したアイドルフレームが、カウンタによってカウントされる。脱落したアイドルフレームの数は、タイミング情報として使用される。]
[0039] 好ましくは、従来のＧＦＰに基本的に準拠するデータストリームが、生成され、このデータストリームは、ＧＦＰアイドルフレームを有する。これらのＧＦＰアイドルフレームが、除去され、後続のＧＦＰクライアントデータフレーム（後続のクライアントパケットに対応する）の間の脱落したアイドルフレームが、カウントされる。代替として、ＧＦＰアイドルフレームを前もって挿入することなく、これらのフレームを後に除去することなしに、脱落したアイドルフレームをカウントしてもよい。]
[0040] 有利には、脱落したアイドルフレームのそれぞれの数は、ＧＦＰヘッダの予備フィールドの中に格納される。さらに、好ましくは、脱落したアイドルフレームのそれぞれの数は、それぞれの脱落したアイドルフレームの直後のＧＦＰクライアントデータフレームの中に（特に、このフレームのヘッダの中に）格納される。]
[0041] 好ましくは、出口ノードにおいて、転送されるべきパケットは、脱落したアイドルフレームの数に基づいて、タイミング制御される。特に、このことは、脱落したアイドルフレームのそれぞれの数に従って、後続のＧＦＰフレームの間にＧＦＰアイドルフレームを挿入することによって実行されることが可能である。]
[0042] 前述したとおり、そのようなネットワークの入口ノードにおける可変のトラフィック負荷は、コンテナの中で伝送されるべきパケットを蓄積することに関する可変の蓄積時間をもたらす。蓄積時間の、この不確実性は、出口ノードにおけるコンテナ着信の時間的ばらつきをもたらし、このため、集約解除後のパケット着信の大きいジッタをもたらす。]
[0043] この問題を克服するために、好ましくは、コンテナに関する最も早いパケットが、異なるコンテナの中のそれぞれの最も早いパケットを、基本的に一定である義務的な期間にわたって入口ノードと出口ノードにおいて同時に待つように取り計らう。好ましくは、完全な期間は、入口ノードの負荷に応じて、入口ノードと出口ノードの間で分割される。例えば、低い負荷の場合において、最も早いパケットは、入口ノードにおいて、より大きい時間間隔にわたって待ち（コンテナは、大きい時間間隔内に埋められるので）、出口ノードにおいて、より小さい時間間隔にわたって待つ。これとは対照的に、重い負荷の場合、最も早いパケットは、入口ノードにおいて、より小さい時間間隔にわたって待ち（コンテナは、小さい時間間隔内に埋められるので）、出口ノードにおいて、より長い時間間隔にわたって待つ（入口ノードにおける、より短い時間間隔を補償するように）。このため、トラフィック負荷に起因する入口ノードにおける蓄積時間の変化は、出口ノードにおける待機時間の逆の変化によって補償される。例えば、変形されたフレーミングプロシージャを、この着想と組み合わせて使用している場合、クライアントフロータイミングは、実際の負荷とは無関係に、正確に再現されることが可能である。]
[0044] 好ましい実施形態によれば、各パケットは、コンテナの中のすべてのパケット、さらに異なるコンテナの中のパケットを基本的に一定である期間にわたって入口ノードと出口ノードにおいて同時に義務的に待つ。このことは、異なるコンテナの中の最も早いパケットに関する待機時間が一定であり、各コンテナの中のその他のパケットのタイミングが、この最も早いパケットとの関係で出口ノードにおいて再構築される場合に当てはまる。]
[0045] 実際のパケットサイズ、密度、トラフィック負荷、またはコンテナ粒度にかかわらず、任意のパケットに関して一定の遅延は、光ファイバケーブル上のファイバ遅延と均等である。コンテナ交換コアの外部のネットワークアプリケーションは、両方の遅延寄与を区別することができない。]
[0046] 好ましくは、それぞれのコンテナの中で伝送されるべき、最も早い受信されたパケットに関して、所定のタイムアウト期間に達したかどうかが、入口ノードにおいて監視される。最悪ケースにおいて、最も早いパケットは、タイムアウト期間まで入口ノードにおいて待つ。タイムアウト期間に達した場合、コンテナは、そのコンテナが一杯であるかどうかにかかわらず、伝送の準備ができている。タイムアウト期間に達することは、非常に低い負荷の場合に生じる。通常の負荷、または重い負荷の場合、入口ノードにおける蓄積されたパケットが、コンテナ容量の所定の部分（例えば、完全なコンテナ容量）に既に達している際、最も早いパケットに関してタイムアウト期間の一部分だけしか、経過していない。]
[0047] 入口ノードにおいて、コンテナは、（非常に低い負荷の場合）最も早いパケットに関して所定のタイムアウト期間に達すると、または（通常の負荷、または重い負荷の場合）入口ノードにおける蓄積したパケットが、コンテナ容量の所定の部分に達すると、伝送の準備ができている。出口ノードにおいて、最も早いパケットは、タイムアウト期間の経過していない部分（すなわち、タイムアウト期間に達している場合、０であることが可能な、タイムアウト期間の残り）に基づいてタイミング制御され、さらにコンテナの中の残りのパケットは、タイミング情報に基づいてタイミング制御されて、コンテナの中のパケットの、互いに対する相対的タイミングが再現される。最も早いパケットは、タイムアウト期間の経過していない部分にわたって正確に待った後、伝送のために義務的に解放されるわけではないことに留意されたい。最も早いパケットは、すべてのパケットに関して一定である、さらなる遅延を伴って、後に解放されてもよい。]
[0048] 最も早いパケットに関する合計待機時間は、タイムアウト期間の経過した部分（入口ノードにおける待機時間または累積時間に相当する）に、タイムアウト期間の経過していない部分（出口ノードにおける待機に相当する）を足した結果であることが可能である。もちろん、最も早いパケットに関する合計待機時間は、例えば、出口ノードにおいて、一定の遅延分だけ増加されてもよい。]
[0049] 好ましい実施形態によれば、入口ノードにおいて、パケットは、第１のバッファの中、例えば、第１のＦＩＦＯバッファ（先入れ先出し）の中に蓄積される。出口ノードにおいて、受信されたコンテナのコンテンツは、第２のバッファの中、例えば、第２のＦＩＦＯバッファの中に格納される。]
[0050] したがって、好ましくは、コンテナに関する最も早いパケットは、異なるコンテナの中のそれぞれの最も早いパケットを基本的に一定である義務的な期間にわたって第１のバッファと第２のバッファの中で同時に待つように取り計らう。より好ましくは、各パケットは、コンテナの中のすべてのパケットを、さらに異なるコンテナの中のパケットに関して基本的に一定である期間にわたって第１のバッファと第２のバッファの中で同時に義務的に待つ。]
[0051] 好ましくは、それぞれのコンテナの中で伝送されるべき第１のバッファの中の最も早いパケット（すなわち、ＦＩＦＯバッファの第１のパケット）に関して、所定のタイムアウト期間に達したかどうかが監視される。また、第１のバッファが、所定の充填サイズ（例えば、最大コンテナペイロードサイズに対応する充填サイズ）に達したかどうかも監視される。]
[0052] 第１のバッファのコンテンツは、（非常に低い負荷の場合）最も早いパケットに関して所定のタイムアウト期間に達すると、または（通常の負荷、または重い負荷の場合）第１のバッファが、所定の充填サイズに達すると、伝送の準備ができている（例えば、第１のバッファのコンテンツをコンテナフレームの中に格納し、パケット間の着信距離を、パケットと一緒にコンテナの中に格納し、さらにタイムアウト期間の経過していない部分をコンテナの中に格納して）。]
[0053] 最も早いパケットは、タイムアウト期間の経過していない部分に基づいて（すなわち、タイムアウト期間の残りに基づいて）タイミング制御されて、出口ノードにおいて第２のバッファから解放される。このため、入口ノードにおける蓄積時間の変化は、出口ノードにおいて解放することに関する時間の、逆の意図的な変化によって補償される。コンテナの中の残りのパケットは、タイミング情報に基づいてタイミング制御されて、第２のバッファから解放されて、パケットの、互いに対する相対的タイミングが再現される。「タイムアウト期間の経過していない部分に基づいてタイミング制御される」とは、最も早いパケットが、タイムアウト期間の経過していない部分を待った直後に、伝送のために必然的に解放されることは意味しないことに留意されたい。最も早いパケットは、すべてのパケットに関して一定である、さらなる遅延を伴って、後に解放されてもよい。]
[0054] 有利には、最も早いパケットと関係するタイミング情報は、入口ノードにおいて決定され、ネットワークを介して伝送されもする。最も早いパケットと関係する、伝送されるタイミング情報は、タイムアウト期間の経過していない部分を示すことも可能である。最も早いパケットのタイミング情報は、タイムアウト期間の経過していない部分に設定されることが可能である。そのような経過していない部分は、タイムアウト期間に達している場合、０であることが可能である。]
[0055] 好ましい実施形態によれば、コンテナは、イーサネット（登録商標）ジャンボフレームである。ＩＥＥＥ８０２．３によれば、イーサネット（登録商標）フレームは、１５１８バイト（ＩＰの場合、１５００バイト）の最大サイズを有する。ジャンボフレームは、すべて、１５１８バイト（１５００バイト）という、このサイズを超えるイーサネット（登録商標）フレーム、例えば、９．６キロバイト以上のサイズを有するイーサネット（登録商標）フレームである。]
[0056] 本発明は、毎秒１０ギガビットまたは毎秒１００ギガビットのイーサネット（登録商標）トランスポートネットワークのために使用されることが可能である。毎秒１００ギガビットは、純粋なトランスポート技術であり、アプリケーションは、毎秒１００ギガビットで動作するものと予期されない。このため、潜在的にすべての毎秒１００ギガビットのイーサネット（登録商標）製品が、本発明から利益を受けることが可能である。]
[0057] 本発明の前述した実施形態は、任意の組み合わされることが可能であることに留意されたい。特に、変形された汎用フレーミングプロシージャによってクライアントパケットを符号化するという概念が、入口ノードと出口ノードにおいて一定の待機時間を設けるという概念と組み合わされることが可能である。さらに、本発明の開示は、従属請求項における後方参照によって明示的に与えられる請求項組み合わせ以外の他の請求項組み合わせも範囲に含み、すなわち、請求項は、基本的に任意の順序で組み合わされることが可能であることに留意されたい。]
[0058] 本発明の第２の態様は、パケットトランスポートネットワークの入口ノードのためのネットワーク要素に関する。このネットワーク要素は、ネットワークを介して伝送されるべき１つまたは複数のクライアント信号のパケットを受信し、蓄積するように構成される。このネットワーク要素は、パケットのタイミングを特徴付けるタイミング情報を決定するための決定手段を備える。さらに、受信されたパケットをコンテナの中にマッピングするためのマッピング手段が、提供される。また、ネットワークは、ネットワークを介してコンテナおよびタイミング情報を伝送するための伝送手段を備える。]
[0059] 本発明の第３の態様は、そのようなネットワークの出口ノードのためのネットワーク要素に関する。このネットワーク要素は、本発明の第２の態様によるネットワーク要素によってマッピングされたコンテナを受信するために構成される。出口ノードに関するネットワーク要素は、コンテナからパケットを抽出するための抽出手段と、タイミング情報に基づいて、さらなる伝送のためにパケットをタイミング制御するためのタイミング手段とを備える。]
[0060] 本発明の第４の態様は、パケットトランスポートネットワークに関する。ネットワークの入口ノードにおいて、ネットワークは、本発明の第２の態様による第１のネットワーク要素を備える。ネットワークの出口ノードにおいて、ネットワークは、本発明の第３の態様による第２のネットワーク要素を備える。ネットワークは、さらなるネットワークノード、特に、入口ノードと出口ノードの間にスイッチングノードを備えることが可能であるが、そのような追加のネットワークノードは、義務的ではない。入口ノードにおけるネットワーク要素と、出口ノードにおけるネットワーク要素は、同一のカプセル化フォーマットを使用する。このカプセル化フォーマットは、企業標準において、または公開標準において標準化されることが可能である。トランスポートネットワークにおけるネットワークスイッチは、これらのスイッチが、コンテナフォーマット自体、例えば、イーサネット（登録商標）ジャンボフレームを知っている限り、特定のカプセル化フォーマットを必ずしも知らなくてもよい。]
[0061] 本発明の第１の態様、および本発明の好ましい実施形態による方法と関係する以上の所見は、本発明の第２の態様から第４の態様によるネットワーク要素およびネットワークにも当てはまる。]
[0062] 本発明は、添付の図面を参照して例として後段で説明される。]
図面の簡単な説明

[0063] 従来の高速コアネットワークを有する従来の階層ネットワークにおけるクライアントパケットフローを示す図である。
コアネットワークの負荷が重い場合におけるパケット集約を伴うパケットトランスポートネットワークを有する階層ネットワークにおけるクライアントパケットフローを示す図である。
図２のネットワークの負荷が低い場合におけるクライアントパケットフローを示す図である。
本発明の方法の第１の実施形態を示す図である。
本発明の方法の第２の実施形態を示す図である。] 図２
実施例

[0064] 図１から図３は、前段で既に説明した。図４は、パケット集約を伴うパケットトランスポートネットワーク、例えば、バースト交換ネットワークを介してクライアント信号を伝送する本発明の方法の第１の実施形態を示す。この方法は、以下に説明されるとおり、標準のＧＦＰ（汎用フレーミングプロシージャ）の拡張によって実施される。] 図１ 図３ 図４
[0065] クライアントパケット３０ａ、３０ｂ、３０ｃが、例えば、様々な時刻ｔ１、ｔ２、およびｔ３にネットワークの入口ノードに着信する。図４において、クライアントパケット３０ａ、３０ｂ、３０ｃは、異なるクライアント信号と関係する。クライアントパケット３０ａ、３０ｂ、３０ｃは、例えば、イーサネット（登録商標）フレームおよび／またはＩＰ／ＰＰＰフレームであることが可能である。] 図４
[0066] クライアントパケット３０ａ、３０ｂ、３０ｃは、ＧＦＰ符号化されたビットストリームに符号化され、すなわち、パケット３０ａ、３０ｂ、３０ｃは、ＧＦＰクライアントデータフレーム３１ａ、３１ｂ、３１ｃにマッピングされる。さらに、ＧＦＰアイドルフレーム３２が、クライアントパケット３０ａ、３０ｂ、３０ｃの間のギャップを補償するようにＧＦＰクライアントデータフレーム３１ａ、３１ｂ、３１ｃの間に配置される。]
[0067] 以下の２つのマッピングモード、すなわち、図４において使用されるフレームマッピングされたＧＦＰ（ＧＦＰ−Ｆ）、およびトランスペアレントマッピングされたＧＦＰ（ＧＦＰ−Ｔ）が、ＧＦＰに存在する。] 図４
[0068] ＧＦＰ−Ｆにおいて、基本的にクライアントパケット全体が、ＧＦＰクライアントデータフレームの中にマッピングされるのに対して、ＧＦＰ−Ｔ複数８Ｂ／１０Ｂブロック符号化されたクライアントデータストリームは、ＧＦＰフレームにマッピングされる。ＧＦＰ−Ｆは、通常、イーサネット（登録商標）クライアント信号またはＩＰ／ＰＰＰクライアント信号のために使用されるのに対して、ＧＦＰ−Ｔは、ファイバチャネルクライアント信号、ＥＳＣＯＮ（エンタープライズシステムズコネクション）クライアント信号、またはＦＩＣＯＮ（ファイバ接続）クライアント信号の場合に適用される。]
[0069] 各ＧＦＰクライアントデータフレーム３１ａ、３１ｂ、３１ｃは、コアヘッダフィールド（図示せず）を備え、コアヘッダフィールドは、ＧＦＰフィールド、特に、ペイロードの長さを記述する。さらに、各ＧＦＰクライアントデータフレーム３１ａ、３１ｂ、３１ｃは、ペイロード領域を備え、ペイロード領域は、ペイロードヘッダ３１．１ａ、３１．１ｂ、３１．１ｃと、ペイロード情報フィールド３１．２ａ、３１．２ｂ、３１．２ｃとを有する。クライアントパケット３０ａ、３０ｂ、３０ｃは、ペイロード情報フィールド３１．２ａ、３１．２ｂ、３１．２ｃにマッピングされる。]
[0070] ＧＦＰクライアントデータフレーム３１ａ、３１ｂ、３１ｃの間のＧＦＰアイドルフレーム３２（特別なＧＦＰ制御フレームを形成する）は、コアヘッダフィールドを備えるが、ペイロード領域は全く備えず、それぞれ４バイトの長さを有する。]
[0071] ２つの後続のＧＦＰクライアントデータフレーム３１ａ、３１ｂ、３１ｃの間のＧＦＰアイドルフレーム３２は、カウンタによってカウントされる。カウンタ値は、カウントされたＧＦＰアイドルフレーム３２によって形成されるそれぞれアイドル期間の直後のＧＦＰクライアントデータフレームのＧＦＰペイロードヘッダの予備フィールドの中に格納される。特に、このカウンタ値は、ペイロードヘッダの一部として拡張ヘッダの予備フィールドの中に格納されることが可能である。代替として、拡張ヘッダ識別子（ＥＸＩ）フィールドは、さらなるタイプ定義を許すので、新たな拡張ヘッダタイプを定義してもよい。拡張ヘッダのサイズは、固定ではなく、タイプに応じて０バイトから５８バイトまでの間で異なることが可能である。]
[0072] ＧＦＰペイロードヘッダ３１．１ａ、３１．１ｂ、３１．１ｃの中に、このカウンタ値を格納する代わりに、このカウンタ値は、ＧＦＰコアヘッダの中に、または拡張されたＧＦＰコアヘッダの中に格納されてもよい。]
[0073] さらに、ＧＦＰアイドルフレームは、ビットストリームから除去される。脱落したアイドルフレームをカウントするステップと、それらのアイドルフレームを除去するステップはともに、ＩＴＵ−Ｔ Ｇ．７０４１勧告において規定される従来のＧＦＰの一部ではない。このため、この実施形態において、変形されたＧＦＰが、実行される。]
[0074] ペイロードヘッダフィールド３１．１ａ、３１．１ｂ、３１．１ｃ（図４に示される、脱落したアイドルフレームの数を備える「ヘッダ＊」を参照）の中に脱落したＧＦＰアイドルフレームの数を備えるＧＦＰクライアントデータフレーム３１ａ、３１ｂ、３１ｃは、コンテナ３３、例えば、バーストコンテナ３３の中に次々に直接にマッピングされる。] 図４
[0075] ネットワークの様々なノードを介してコンテナ３３を伝送する際、コンテナ３３のペイロード、すなわち、パケット３１ａ、３１ｂ、および３１ｃ、ならびにこれらのパケット３１ａ、３１ｂ、および３１ｃのヘッダは、ネットワークノードには不可視であり、その結果、コンテナ３３のヘッダ（図示せず）だけが処理される必要があり、カプセル化されたパケットのヘッダは、処理される必要がないので、ヘッダ処理のための労力が減らされる。]
[0076] ネットワークを介する伝送の後、プロセスは、出口ノードにおいて、すなわち、アンロード段階において逆転され、パケット着信プロセスは、ヘッダフィールド３１．１ａ、３１．１ｂ、３１．１ｃの中に格納された、訂正された出発距離を再確立することによって模倣される。正しい数のアイドルフレームが、ペイロードヘッダフィールド３１．１ａ、３１．１ｂ、３１．１ｃの中に格納された脱落したアイドルフレームの伝送されたカウンタ値に基づいて、さらにパケット自体が、さらなる伝送のためにコンテナから解放される前に、再現される。]
[0077] 正しい数のアイドルフレームが、受信されたＧＦＰクライアントデータフレーム３１ａ、３１ｂ、３１ｃの間に挿入され、その結果、入口ノードにおけるタイミングが再構築される。最期に、クライアントパケット３０ａ、３０ｂ、３０ｃが、再構築されたタイミングでＧＦＰ符号化されたビットストリームから逆マッピングされる。アクセスネットワークを介する伝送のためのクライアントパケット３０ａ、３０ｂ、３０ｃの出発タイミングは、入口ノードにおけるクライアントパケット３０ａ、３０ｂ、３０ｃの着信タイミングに基本的に対応する。]
[0078] 前述したとおり、そのようなネットワークの入口ノードにおける可変のトラフィック負荷は、コンテナに割り当てられたパケットを蓄積することに関する可変の蓄積時間をさらにもたらす。蓄積時間の、この不確実性は、出口ノードにおける後続のコンテナの間で遅延の時間的ばらつきをもたらし、このため、集約解除の後のパケット着信のジッタをもたらす。トラフィック変動に起因する蓄積時間のそのような変化は、本発明の方法の第２の実施形態において後段で説明されるとおり、補償されることが可能である。その結果、同一のコンテナの中のパケットの相対的タイミングだけでなく、異なるコンテナの中のパケットの相対的タイミングも、出口ノードにおいて再構築される。]
[0079] 図５に示される本発明の方法の第２の実施形態は、以下のステップによって、コンテナの中にクライアントパケットを集約すること、および伝送されたコンテナからクライアントパケットを集約解除することを実行する。すなわち、
１．高速パケットトランスポートネットワークの入口ノードにおいて、様々なソースからの着信クライアントパケット４０ａ−４０ｅにタイムスタンプが押される。
２．着信クライアントパケット４０ａ−４０ｅが、出口ノードにおける第１のＦＩＦＯバッファ４１の中にパケット４０ａ−４０ｅを格納することによって蓄積される。
３．（非常に低い負荷の場合）第１のＦＩＦＯバッファ４１の中の第１のパケット４０ｅに関してタイムアウト期間Ｔｏに達すると、または（通常の負荷、または重い負荷の場合）第１のＦＩＦＯバッファ４１の充填が、最大コンテナフレームサイズに達すると、以下のステップが、実行される。すなわち、
３．１ 第１のＦＩＦＯバッファ４１のコンテンツ全体が、コンテナフレーム４２（例えば、イーサネット（登録商標）ジャンボフレーム）の中に入れられ、ＦＩＦＯバッファ４１は、空にされる。
３．２ タイムスタンプによるタイミング情報、例えば、パケットの間、特に、後続のパケットの間の着信距離、または或るパケットの末尾と次のパケットの先頭の間の距離が、コンテナフレーム４２の中に格納される。このことは、パケットの中に、このタイミング情報を格納することによって、例えば、図４に関連して説明されるとおり、パケットの変形されたヘッダの中に、このタイミング情報（この場合、省略されたアイドルフレームの数）を格納することによって、行われることが可能である。
３．３ 第１のパケット４０ｅのタイミング情報、例えば、第１のパケット４０ｅの着信距離が、タイムアウト期間の経過していない部分に（すなわち、タイムアウト期間の残りに）設定される。タイムアウト期間の経過していない部分は、タイムアウトに達している場合、０である。
４．次に、コンテナフレーム４２が、高速コアネットワークを介して伝送される。高速コアネットワークのスイッチングノードにおいて、コンテナ４２のコンテンツ、特に、パケットのヘッダは、不可視である。
５．受信側出口ノードにおいて、コンテナ４２のコンテンツが、第２のＦＩＦＯバッファ４３の中に入れられる。タイムアウト期間の０の残り、または０でない残りを示すことが可能な第１のパケットを含め、パケット４０ａ−４０ｅが、格納された距離に応じて解放される。０の残りの場合、第１のパケット４０ｅは、即時に解放され、その他のパケット４０ａ−４０ｄは、格納された距離で解放される。０でない残りの場合、第１のパケット４０ａは、タイムアウト期間の残りが経過した後に解放され、その他のパケット４０ａ−４０ｄは、格納された距離で解放される。] 図４ 図５
[0080] ＦＩＦＯバッファ４１の先頭が、タイムアウトに達した場合、デリバリは、タイムアウト制御される。第１のＦＩＦＯバッファ４２の充填が、最大ジャンボフレームサイズに達した場合、デリバリは、フレームサイズ制御される。]
[0081] しかし、両方のシナリオにおいて、各パケット４０ａ−４０ｅは、合わせて一定のタイムアウト期間Ｔｏにわたって第１のＦＩＦＯバッファ４１と第２のＦＩＦＯバッファ４３の中で待たなければならない。このことは、いくつかの例を参照して後段で説明される。]
[0082] 第１のパケットが、空の第１のＦＩＦＯバッファ４１の中に時刻ｔ１に着信した場合、タイムアウト制御されるシナリオの事例において、第１のパケットは、時刻ｔ＝ｔ１＋Ｔｏまで第１のＦＩＦＯバッファ４１の中で待つ。第１のＦＩＦＯバッファ４１の中の第１のパケットの待機時間は、□ｔ（１）＝Ｔｏである。この第１のパケットに関する相対的距離は、タイムアウト期間Ｔ０の残りに、すなわち、０に設定される。伝送の後、第１のパケットは、第２のＦＩＦＯバッファ４３から即時に解放され、すなわち、第２のＦＩＦＯバッファ４３の中の第１のパケットの待機時間は、□ｔ（２）＝０である。したがって、合計の待機時間は、□ｔ＝□ｔ（１）＋□ｔ（２）＝Ｔｏである。]
[0083] 第２のパケットが、時刻ｔ２に第１のパケットより後に着信した（第１のパケットは、時刻ｔ１に着信している）場合、第２のパケットは、第１のパケットがタイムアウトするまで、すなわち、ｔ＝ｔ１＋Ｔｏまで第１のＦＩＦＯバッファ４１の中で待つ。第１のＦＩＦＯバッファ４１の中の第２のパケットの待機時間は、□ｔ（１）＝ｔ−ｔ２＝（ｔ１＋Ｔｏ）−ｔ２＝Ｔｏ−（ｔ２−ｔ１）である。受信側で、第１のパケットだけが、即時に解放される。後続の第２のパケットは、第１のパケットを基準とした着信距離ｔ２−ｔ１に従って、すなわち、□ｔ（２）＝ｔ２−ｔ１という待機時間の後、第２のＦＩＦＯバッファ４３から解放される。このため、合計待機時間は、□ｔ＝□ｔ（１）＋□ｔ（２）＝Ｔｏ−（ｔ２−ｔ１）＋（ｔ２−ｔ１）＝Ｔｏであり、Ｔｏは、一定である。]
[0084] 同一の待機時間が、フレームサイズ制御されたシナリオの事例で生じる。タイムアウト期間が経過する前に、その後、完全に埋められる、空の第１のＦＩＦＯバッファ４１の中に、時刻ｔ１に着信する第１のパケットを想定されたい。第１のＦＩＦＯバッファ４１は、時刻ｔに一杯になり、ｔ＜ｔ１＋Ｔ０である。この場合、第１のバッファ４１における待機時間は、□ｔ（１）＝ｔ−ｔ１＜Ｔ０である。この第１のパケットに関する相対的距離は、タイムアウト期間Ｔ０の残りに、すなわち、Ｔ０−□ｔ（１）に設定される。受信側で、コンテナの受信の後、第１のパケットは、この場合、０ではない相対的距離□ｔ（２）＝Ｔ０−□ｔ（１）にわたって待たなければならない。このため、合計の待機時間は、この場合も、□ｔ＝□ｔ（１）＋□ｔ（２）＝□ｔ（１）＋（Ｔ０−□ｔ（１））＝Ｔ０である。残りのパケットは、入口ノードにおけるタイミングに応じて、第１のパケットを基準にして解放され、つまり、残りのパケットの合計の待機時間もやはり、□ｔ＝□ｔ（１）＋□ｔ（２）＝Ｔ０である。]
[0085] もちろん、すべてのパケットに関する合計の待機時間は、オプションとして、さらなる一定の遅延分だけ増加されてもよいことに留意されたい。例えば、タイムアウト制御されたデリバリの場合、第１のパケットは、即時に解放されるのではなく、さらなる一定の期間の後に解放される。]
[0086] 実際のパケットサイズ、密度、トラフィック負荷、またはコンテナ粒度にかかわらない、任意のパケットに関する一定の遅延は、光ファイバケーブル上のファイバ遅延と均等である。コンテナ交換コアの外部のネットワークアプリケーションは、両方の遅延寄与を区別することができない。]
[0087] 第２の実施形態に関するサイズ設定の例として、毎秒１０ギガビットのイーサネット（登録商標）リンク、ならびに９．６キロバイトのサイズを有するイーサネット（登録商標）ジャンボフレームの中にクライアントパケットをカプセル化することを想定することができる。最大パケットレートは、リンク容量を最小パケットサイズで割った値として計算されることが可能である。ジャンボフレームの中にパケットを集約することなく、ＴＣＰＡＣＫパケットの場合に６４バイトの最小パケットサイズを想定すると、イーサネット（登録商標）リンクのラインカードにおける最大パケットレートは、毎秒１０ギガバイト／（６４バイト・８ビット／バイト）＝１９Ｍｐｐｓ（１秒当たりのパケット数）である。ジャンボフレームの中にクライアントパケットを集約することで、最大パケットレートは、毎秒１０ギガバイト／（９．６キロバイト＊８ビット／バイト）＝１３０ｋｐｐｓ、すなわち、リンク容量を、９．６キロバイトのジャンボフレームサイズで割った値として計算されることが可能である。このため、ジャンボフレームの中に集約することは、パケット処理が１／１００未満に緩和されることになる。]
[0088] タイムアウト期間Ｔ０をＴ０＝１ミリ秒に設定する場合、そのようなタイムアウト期間は、２００キロメートルのさらなるファイバ距離（ネットワークのスイッチングノード間ではなく、終端間）の遅延、または中間スイッチのうちの１つにおける１．２５メガバイトのキューサイズにほぼ相当する。]
[0089] 最大ジャンボフレームサイズは、或る特定のパス上のトラフィック負荷が、ジャンボフレームサイズをタイムアウト期間Ｔ０で割った値、すなわち、（９．６キロバイト・８ビット／バイト）／１ミリ秒＝毎秒７７メガビットと少なくとも等しい場合に、タイムアウト期間Ｔ０内に入口ノードにおいて達せられる。このトラフィックは、リンク容量の１／１００未満である。このため、非常に低いトラフィックの場合にだけ、デリバリは、タイムアウト制御される。]

权利要求:

請求項1
パケットトランスポートネットワークを介してパケットを伝送する方法であって、ネットワークの入口ノード（３’）において、１つまたは複数のクライアント信号（２）のパケット（３０ａ−ｃ、４０ａ−ｅ）を受信して、蓄積するステップと、受信されたパケット（３０ａ−ｃ、４０ａ−ｅ）のタイミングを特徴付けるタイミング情報を決定するステップと、蓄積されたパケット（３０ａ−ｃ、４０ａ−ｅ）をコンテナ（２０ａ−ｄ、３３、４２）の中にマッピングするステップとを備え、ネットワークを介してコンテナ（２０ａ−ｄ、３３、４２）およびタイミング情報を伝送するステップと、ネットワークの出口ノード（７’）において、コンテナ（２０ａ−ｄ、３３、４２）を受信するステップと、コンテナ（２０ａ−ｄ、３３、４２）からパケット（３０ａ−ｃ、４０ａ−ｅ）を抽出し、パケット（３０ａ−ｃ、４０ａ−ｅ）を、タイミング情報に基づいて、さらなる伝送のためにタイミング制御するステップとを備える、方法。
請求項2
それぞれのコンテナ（４２）の中で伝送されるべきそれぞれの最も早く受信されたパケット（４０ｅ）が、基本的に一定の期間を同時に入口ノードと出口ノードにおいて待ち、入口ノードにおける期間の部分と、出口ノードにおける期間の部分との間の比が、入口ノードの負荷に依存する、請求項１に記載の方法。
請求項3
決定するステップ、およびマッピングするステップが、変形された汎用フレーミングプロシージャ（ＧＦＰ）によって受信されたパケット（３０ａ−ｃ）を符号化するステップであって、ＧＦＰ特有のアイドルフレーム（３２）が脱落させられるステップと、脱落したアイドルフレーム（３２）をカウントするステップとを備える、請求項１に記載の方法。
請求項4
符号化するステップが、基本的にＧＦＰに準拠して、ＧＦＰ特有のアイドルフレーム（３２）を有するデータストリームを生成するステップと、アイドルフレーム（３２）を除去するステップとを備える、請求項３に記載の方法。
請求項5
決定するステップ、およびマッピングするステップが、脱落したアイドルフレーム（３２）の数をＧＦＰヘッダ（３１．１ａ−ｃ）の予備フィールドの中に格納するステップを備える、請求項３に記載の方法。
請求項6
脱落したアイドルフレーム（３２）のそれぞれの数が、それぞれの脱落したアイドルフレーム（３２）の直後のパケットのＧＦＰヘッダ（３１．１ａ−ｃ）の中に格納される、請求項５に記載の方法。
請求項7
タイミング制御するステップが、脱落したアイドルフレーム（３２）の数によって示されるとおり、アイドルフレーム（３２）を挿入するステップを備える、請求項３に記載の方法。
請求項8
コンテナ（４２）の中の伝送されるべき最も早く受信されたパケット（４０ｅ）に関して、入口ノードにおいて所定のタイムアウト期間に達したかどうかを監視するステップをさらに備える、請求項１に記載の方法。
請求項9
入口ノードにおける蓄積されたパケット（４０ａ−ｅ）が、コンテナ容量の所定の部分に達したかどうかを監視するステップをさらに備え、入口ノードにおいて、最も早いパケット（４０ｅ）に関して所定のタイムアウト期間に達すると、または蓄積されたパケット（４０ａ−ｅ）が、コンテナ容量の所定の部分に達すると、コンテナ（４２）が、伝送の準備ができ、さらに出口ノードにおいて、最も早いパケット（４０ｅ）が、タイムアウト期間の経過していない部分に基づいてタイミング制御され、コンテナ（４２）の中の残りのパケット（４０ａ−ｄ）が、タイミング情報に基づいてタイミング制御されて、互いに対するパケットの相対的タイミングが基本的に再現される、請求項８に記載の方法。
請求項10
入口ノードにおいて、第１のバッファ（４１）の中にパケット（４０ａ−ｅ）を格納するステップと、出口ノードにおいて、第２のバッファ（４３）の中に、受信されたコンテナ（４２）のコンテンツを格納するステップとをさらに備え、第１のバッファ（４１）の中のコンテナ（４２）に関する最も早いパケットに関して、所定のタイムアウト期間に達したかどうかが監視され、さらに最も早いパケットに関して所定のタイムアウト期間が経過すると、コンテナに関する第１のバッファ（４１）のコンテンツが、伝送の準備ができる、請求項８に記載の方法。
請求項11
第１のバッファ（４１）が所定の充填サイズに達したかどうかを監視するステップをさらに備え、第１のバッファ（４１）が、所定の充填サイズに達すると、第１のバッファ（４１）のコンテンツが、伝送のために処理され、最も早いパケット（４０ｅ）が、タイムアウト期間の経過していない部分に基づいてタイミング制御されて、第２のバッファ（４３）から解放され、さらにコンテナ（４２）の残りのパケット（４０ａ−ｄ）が、タイミング情報に基づいてタイミング制御されて、第２のバッファ（４３）から解放されて、互いに対するパケットの相対的タイミングが基本的に再現される、請求項１０に記載の方法。
請求項12
最も早いパケットと関係する伝送されたタイミング情報が、タイムアウト期間の経過していない部分を示す、請求項９に記載の方法。
請求項13
コンテナ（４２）が、イーサネット（登録商標）ジャンボフレームである、請求項１に記載の方法。
請求項14
パケットトランスポートネットワークの入口ノード（３’）のためのネットワーク要素であって、ネットワークを介して伝送されるべき１つまたは複数のクライアント信号（２）のパケット（３０ａ−ｃ、４０ａ−ｅ）を受信して、蓄積するための手段と、パケット（３０ａ−ｃ、４０ａ−ｅ）のタイミングを特徴付けるタイミング情報を決定するための決定手段と、蓄積されたパケット（３０ａ−ｃ、４０ａ−ｅ）をコンテナ（２０ａ−ｄ、３３、４２）の中にマッピングするためのマッピング手段と、ネットワークを介してコンテナ（２０ａ−ｄ、３３、４２）およびタイミング情報を伝送するための伝送手段とを備える、ネットワーク要素。
請求項15
パケットトランスポートネットワークの出口ノード（７’）のためのネットワーク要素であって、ネットワークの入口ノード（３’）において請求項１４に記載のネットワーク要素によって生成されたコンテナ（２０ａ−ｄ、３３、４２）を受信するための受信手段と、コンテナ（２０ａ−ｄ、３３、４２）からパケット（３０ａ−ｃ、４０ａ−ｅ）を抽出するための抽出手段と、タイミング情報に基づいて、さらなる伝送のためにパケット（３０ａ−ｃ、４０ａ−ｅ）をタイミング制御するためのタイミング手段とを備える、ネットワーク要素。
請求項16
パケットトランスポートネットワークの入口ノード（３’）における、請求項１４に記載の第１のネットワーク要素と、パケットトランスポートネットワークの出口ノード（７’）における、請求項１５に記載の第２のネットワーク要素とを備える、パケットトランスポートネットワーク。